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ABSTRACT 

This  paper  extends  the  conceptual  model  of  the  "STONEMAN"  document 
to  more  completely  model  the  interfaces  and  protocols  that  exist 
in  the  Ada  Programming  Support  Environment  (APSE).  A  previous 
extension  to  the  STONEMAN  model  is  reviewed  and  critiqued,  the 
guidelines  for  the  APSE  set  forth  in  STONEMAN  are  reviewed,  and  an 
updated  model  is  proposed.  The  new  model  is  shown  to  meet  the 
guidelines  set  forth  in  STONEMAN,  and  to  include  subsequent  ideas 
as  well.  The  new  model  is  then  applied  to  the  problem  of  user 
communication  with  an  APSE,  and  it  is  shown  how  the  new  model 
extends  to  include  distributed  APSEs  as  well  as  single  host  APSEs. 
The  issue  of  security  enforcement,  as  a  necessary  subset  of 
dynamic  validation,  is  also  included  in  the  new  model. 
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I .  INTRODUCTION 

A  fundamental  objective  of  the  Department  of  Defense  (DoD) 
initiative  to  develop  Ada  was  to  increase  the  portability  and 
maintainability  of  embedded  software  [1]*.  To  achieve  this 
objective,  the  Ada  Joint  Program  Office  (AJPO)  is  workina  to 
ensure  that  Ada  remains  as  independent  of  specific  computing 
systems  and  applications  as  possible.  The  Ada  language  has  been 
accepted  by  the  American  National  Standards  Institute  (ANSI)  as  a 
national  standard,  and  has  been  proposed  to  the  International 
Organization  for  Standardisation  (ISO)  as  an  international 
standard.  The  Ada  Validation  Organization  (AVO)  has  been 
established  to  enforce  and  protect  the  trademark  for  the  language. 
However,  the  Ada  project  has  evolved  beyond  an  effort  toward  a 
common  programming  language  for  embedded  software  systems;  work 
has  been  begun  to  define  requirements  for  a  common  Ada  Programming 
Support  Environment  (APSE),  a  Kernal  Ada  Programming  Support 
Environment  (KAPSE),  and  the  Common  APSE  Interface  Set  (CAIS). 
The  CAIS  is  part  of  the  Ada  standardization  effort  because  it  will 
provide  a  standardized  development  and  runtime  environment  for  Ada 
programs . 

A  previous  report,  "Validation  in  Ada  Programming  Support 
Environments"  12],  recommended  that  the  Open  Systems 
Interconnection  Reference  Model  be  accepted  as  the  underlying 
model  of  APSEs,  and  that  there  be  developed  a  'Strawman'  to  extend 


*  Numbers  in  brackets  refer  to  references  at  the  end  of  the 
report. 
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Ada  systems  into  a  networking  environment,  based  on  the  OSI 
Reference  Model.  The  model  proposed  in  [21  will  be  called  a  LAPSE 
(Layered  Ada  Programming  Support  Environment)  in  this  paper.  That 
report  further  suggested  that  the  security  aspects  of  the  design 
of  APSEs  be  investigated  and  that  the  results  of  that  study  be 
incorporated  into  the  Stoneman  requirements  [31.  This  paper  will 
examine  these  ideas  further,  critiquing  the  LAPSE  and  proposing  an 
updated  and  more  detailed  model,  called  the  DAPSE  (Distributed  Ada 
Programming  Support  Environment).  The  DAPSE  models  communication 
between  APSE  tools  through  the  use  of  the  OSI  Reference  Model  but 
takes  into  account  the  need  to  extend  Ada  systems  into  distributed 
environments.  This  model  also  incorporates  a  security  layer,  as 
recommended  by  [ 2 ] . 

II.  REVIEW  OF  LAPSE  MODEL 


This  section  reviews  the  LAPSE  model  suggested  by  [21  (see 
Figure  1).  In  that  report,  the  authors  noted  that  "the  original 
intent  of  the  OSI  Reference  Model  was  not  to  actually  represent  an 
implementation  strategy  but  instead  to  model  those  elements  of  a 
communications  environment  which  need  attention"  (pg.  8).  In 
other  words,  the  OSI  model  was  not  intended  to  force  all 
implementations  to  have  seven  layers,  but  rather  to  encourage  all 
implementors  to  layer  their  implementations,  and  to  clearly 
specify  the  functionality  of  each  layer.  Thus  an  application  of 
the  OSI  model  to  a  specific  implementation  could  quite  conceivably 
merge  several  layers  into  one,  and  split  one  of  the  OSI  layers 
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Figure  1.  LAPSE  Model 
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into  one  or  more  sublayers.  This  argument  was  given  as  a 
justification  for  the  LAPSE  model.  The  LAPSE  model  had  three 
layers,  which  corresponded  conceptually  to  the  upper  three  layers 
of  the  OSI  Reference  Model.  The  bottom  four  layers  of  the  OSI 
model  (typically  implemented  in  hardware)  were  not  indigenous  to 
the  LAPSE.  The  top  layer  of  the  OSI  model  (The  Application  layer) 
was  mapped  onto  the  top  layer  of  the  LAPSE  model,  called  the  APSE 
layer.  If  the  current  environment  was  a  Minimal  Ada  Programming 
Support  Environment,  (MAPSE),  then  the  top  layer  will  only  include 
the  necessary  and  sufficient  toolset,  not  the  user  programs  or 
additional  tools.  Conceptually,  there  is  no  difference  between  an 
APSE  and  a  MAPSE.  The  second  layer  down  (corresponding  to  the  OSI 
Presentation  layer)  was  named  the  Data  Transfer  Layer.  This  layer 
was  to  act  as  an  interface  layer  between  the  APSE  and  the  KAPSE, 
and  to  implement  the  validation  and  security  mechanisms  suggested 
in  the  report.  The  Data  Transfer  layer  accomplished  all  matching 
of  formal  and  actual  parameters,  and  associated  typechecking.  The 
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bottom  layer  was  the  KAPSE  Facilities  layer,  and  was  mapped  onto 
the  Session  layer  of  the  OSI  model.  The  report  [ 2 1  suggested  that 
the  KAPSE  could  be  implemented  as  a  collection  of  Ada  packages. 

The  LAPSE  had  the  advantage  that  it  clearly  delineated  what 
interfaces  and  protocols  existed.  The  report  called  attention  to 
the  existance  of  certain  "hidden  protocols"  within  the  STONEMAN 
model,  and  noted  that  these  presented  a  difficult  validation 
problem.  In  the  LAPSE  model,  these  hidden  protocols  were  no 
longer  hidden;  they  were  revealed  as  KAPSE  layer  to  KAPSE  layer 
communication.  Furthermore,  the  LAPSE  model  was  better  than  the 
STONEMAN  model  because  it  took  into  account  both  validation  and 
security,  by  modeling  the  interfaces  and  protocols  that  must  be 
validated,  and  providing  a  layer  where  dynamic  validation  and 
security  checks  could  be  performed.  The  STONEMAN  model  was  not 
detailed  enough  to  reveal  these  problems  since  it  was  only  two 
dimensional . 

III.  PROBLEMS  WITH  LAPSE  MODEL 

The  LAPSE  model  had  three  basic  problems.  The  first,  and 
most  basic,  was  that  it  made  an  unacceptable  use  of  the  OSI  model. 
Since  the  OSI  Reference  Model  is  a  model  of  a  communications 
environment,  and  not  a  programming  environment,  it  was 
inappropriate  to  fit  the  Ada  Programming  Support  Environment  onto 
only  the  upper  three  layers  of  the  OSI  model.  Nonetheless,  the 
principles  of  the  OSI  model  are  very  much  appropriate  and  ought  be 
adopted  in  the  design  of  the  APSE  environment.  That  is,  the  APSE 
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should  be  layered,  and  the  internal  implementation  of  one  layer 
should  be  changeable  without  necessitating  a  revision  or  rewriting 
of  code  in  the  other  layers.  Furthermore,  specific  functionality 
should  be  assigned  to  each  layer  of  the  implementation,  and  this 
functionality  should  follow  the  overall  design  principle  of 
layered  abstraction,  where  the  services  provided  by  each  layer  are 
implemented  only  in  terms  of  (and  by  calls  to)  the  functionalities 
of  the  layer  immediately  below. 

A  second  problem  with  the  LAPSE  model  was  that  it  failed  to 
take  into  account  (or  even  mention)  the  Data  Base  Conceptual 
Schema  ( 4  J  .  The  APSE  model  should  be  integrated  with  the  data 
base  model,  so  that  the  design  of  the  total  environment  is 
consistent  and  so  that  the  interfaces  between  the  Data  Base  and 
the  KAPSE  are  well  defined  and  easy  to  validate. 

The  third  problem  with  the  LAPSE  model,  and  the  problem  with 
the  STONEMAN  model  before  it,  was  that  the  model  was  not  well 
enough  developed.  It  did  not  show  where  any  the  validation 
mechanisms  were  to  be  installed.  Report  [2]  stated  that  all 
interfaces  and  protocols  must  be  validated  in  order  to  validate 
the  environment,  and  it  was  this  need  that  inspired  the  Data 
Transfer  layer,  where  validation  of  the  APSE  to  KAPSE  interface 
was  to  occur.  The  problem  was  that  this  was  not  the  only  place 
where  validation  of  protocols  or  interfaces  needed  to  occur.  All 
the  horizontal  protocols  between  two  instances  of  layers  at  the 
same  level  must  also  be  validated.  For  instance,  a  compiler 
could  be  communicating  with  an  editor.  Both  these  programs  would 
reside  in  the  top  layer.  The  compiler  and  editor  would 
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communicate  via  a  virtual  protocol  which  would  be  implemented  by 
calls  through  the  interface  to  the  Data  Transfer  layer.  The  Data 
Transfer  layer  services  used  by  the  compiler  and  the  editor  would 
also  communicate  via  a  virtual  protocol  which  would  be  implemented 
by  calls  through  another  interface  to  services  in  the  KAPSE 
Facilities  layer.  The  KAPSE  Facilities  services  would  communicate 
using  an  actual  protocol.  The  LAPSE  model  did  not  provide  a 
mechanism  whereby  the  virtual  protocols  could  be  validated. 
Another  place  where  the  LAPSE  model  needed  furthe’  evelopment  was 
in  the  distinction  between  dynamic  and  static  ilidation.  The 
validation  mechanisms  suggested  in  [2]  are  al]  tatic,  yet  the 
report  suggested  the  creation  of  a  layer  where  *  .idation  could 
occur.  This  validation  would  be  dynamic,  and  the  report  did  not 
expand  upon  the  mechanisms  by  which  the  validation  would  be 
accomplished.  It  should  be  noted  that  there  are  two  types  of 
dynamic  validation:  dynamic  validation  during  the  development 
cycle,  and  dynamic  validation  in  the  runtime  environment.  The 
first  type  of  dynamic  validation  occurs  in  the  Ada  Programming 
Support  Environment  on  the  host  machine,  and  the  second  type  of 
dynamic  validation  occurs  in  the  Ada  Runtime  Environment  on  the 
target  machine.  Both  of  these  sets  of  validation  mechanisms  must 
be  considered  in  any  comprehensive  APSE  model  *. 

The  report  [2]  also  mentioned  the  need  for  some  security 
mechanisms,  and  suggested  that  they  also  be  implemented  in  the 


*  Dynamic,  built-in  "validation"  might  be  better  termed 
"verification";  however,  some  of  the  connotations  of  the  term 
verification  are  outside  the  domain  of  this  report  and  thus  the 
term  validation  is  used  consistently. 
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Data  Transfer  Layer.  However,  (2!  did  not  expand  on  different 
types  of  security  mechanisms,  nor  did  it  distinguish  between 
friendly  and  non-friendly  or  security  intensive  environments  in 
its  discussion  of  the  need  for  security  mechanisms.  If  a  program 
is  allowed  to  operate  in  an  environment  where  security  is 
important,  and  that  program  is  not  secure  or  does  not  meet  the 
security  requirements  associated  with  its  environment,  then  the 
validity  of  that  environment  has  been  jeopardized.  Thus  two 
fundamental  principles  about  security  must  be  recognized:  (1) 
Different  instances  of  Ada  Programming  Support  Environments  may 
have  different  security  requirements,  and  therefore  a  program  that 
is  valid  in  one  instance  of  the  Ada  environment  may  not  be  valid 
in  another  instance  of  the  Ada  environment  because  it  is  not 
secure,  and  (2),  security  is  a  subset  of  validation,  i.e.  a 
program  that  is  not  secure  (enough)  is  not  correct.  These  ideas 
clearly  need  much  more  attention  before  a  final  model  for  Ada 
environments  can  be  approached. 

Most  of  these  issues  were  not  addressed  in  the  previous 
report  because  it  was  preliminary  and  did  not  go  into  the  level  of 
detail  that  would  be  necessary  to  deal  with  all  these  issues. 
This  paper  attempts  to  investigate  all  these  issues  and  refine  the 


model  in 

the  light 

of 

its 

findings . 

Thus 

the  process  of 

successive 

refinement 

of 

the 

model  is 

carried 

one  more  step. 

arriving  at  a  new  model  more  complete  than  the  earlier  model.  No 
doubt  further  iterations  will  need  to  take  place. 


IV.  REQUIREMENTS 


Before  updating  the  previous  model,  the  requirements  for  the 
APSE  should  be  reiterated  and  augmented  by  the  ideas  that  have 
been  put  forward  since  STONEMAN.  The  basic  STONEMAN  philosophy 
[31  emphasized  fourteen  general  guidelines.  Five  among  them  are 
(1)  long  term  software  support,  (2)  host  to  target  system  software 
portability,  and  (3)  an  integrated  database  and  toolset,  (4) 
overall  simplicity,  and  (5)  uniformity  of  protocol.  The  user 
interface  to  the  APSE  programs  or  tools  should  not  be  direct,  but 
should  be  a  virtual  interface  to  the  KAPSE  with  minimal  JCL 
functions  such  as  LOGIN/LOGOUT,  CONNECT/RUN  and  control  character 
processing.  Terminal  interface  drivers  should  not  be  part  of  the 
KAPSE,  but  should  interface  to  it,  much  as  the  APSE  tools  do. 
This  model  of  user  communication  with  the  system  is  similar  to  one 
used  in  many  operating  systems;  user  I/O  is  handled  by  a  special 
I/O  processor  (hardware,  software  or  firmware)  and  buffered  into 
the  kernal  of  the  operating  system.  A  second  concept  that  has 
received  attention  since  STONEMAN  is  the  configuration  or  version 
group,  made  up  of  shareable  objects,  each  of  which  has  a  name  and 
attributes.  Each  object  in  the  version  group  has  a  date  as  one  of 
its  attributes,  with  later  dated  objects  superceeding  earlier  ones 
in  subsequent  configurations.  A  third  concept,  which  is  related 
to  the  second,  is  that  the  APSE  environment  may  in  practice  be 
distributed,  either  between  the  host  and  target  machine  (for  down¬ 
line  loading,  trace  data  collection,  or  emulation)  or  between 
several  hosts  (for  resource  or  information  sharing  or 
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communication) . 


V.  DESCRIPTION  OF  THE  DISTRIBUTED  APSE  (DAPSE)  MODEL 


The  DAPSE  model  (see  figure  2)  is  a  three  layer  version  of 
model  presented  in  (2).  The  top  layer  is  called  the  APSE  layer 


APSE  Layer  > 

Interface  Layer  - > 

KAPSE  Facilities  - > 

Layer 


<  -  APSE  Layer 

<  -  Interface  Layer 

<  -  KAPSE  Facilities 

Layer 


Figure  2.  DAPSE  Model 

since  it  includes  all  APSE  tools  and  application  programs.  It  is 
analogous  to,  but  not  overlayed  upon,  the  Application  layer  of  the 
OSI  Reference  model.  Conceptually,  the  user  visualizes  himself  at 
this  level,  since  the  programs  he  interacts  with  are  contained  in 
this  level:  editors,  compilers,  debuggers,  etc.  If  this  layer 
contains  only  the  minimal  necessary  tools  and  not  any  other  tools 
or  applications  programs,  then  it  is  a  Minimal  Ada  Programming 
Support  Environment  (MAPSE).  Thus  a  MAPSE  is  a  minimal  instance 
of  an  APSE. 

The  middle  layer  is  called  the  Interface  layer.  Interface  is 
meant  in  the  sense  that  it  has  been  used  in  STONEMAN,  and  this 
layer  has  grown  out  of  and  is  an  expansion  of  the  interface  line 
between  the  APSE  and  KAPSE  in  the  STONEMAN  model.  The  parameter 
passing  mechanisms  that  match  the  APSE  actual  parameters  to  the 
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KAPSE  actual  parameters  and  perform  dynamic  typechecking  between 
them  exist  in  this  layer.  These  mechanisms,  formerly  represented 
as  the  thick  line  between  APSE  and  KAPSE,  have  been  made  into  a 
level  due  to  their  complexity.  The  security  mechanisms  called  for 
by  [2)  also  exist  in  this  layer  and  work  along  with  the 
typechecking  mechanisms.  The  principle  is  to  detect  and  stop 
security  exceptions  at  as  early  a  point  as  possible.  This  layer 
dynamically  prevents  protected  KAPSE  packages  from  even  being 
called.  Static  validation  mechanisms  can  show  that  the  Interface 
layer  properly  performs  its  functionalities,  and  then  use  that 
assertion  when  validating  the  KAPSE  facilities.  The  Interface 
layer  performs  all  dynamic  interface  validation,  including  but  not 
restricted  to  typechecking  and  package  access  control.  In 
addition,  any  necessary  data  transformation  operations  may  be 
performed  within  this  layer.  This  layer  can,  like  the  KAPSE,  be 
implemented  as  a  set  of  Ada  packages,  with  a  correspondence 
between  the  names  of  the  KAPSE  level  packages  and  the  Interface 
level  ones.  The  KAPSE  level  packages  will  only  be  visible  from 
the  Interface  layer,  and  the  APSE  programs  must  call  a  KAPSE 
facility  by  calling  the  appropriate  Interface  layer  package.  The 
Interface  layer  will  perform  its  validation  and  conversion 
functions,  and  then  invoke  the  KAPSE  package  with  the  validated 
and  possibly  modified  argument  list. 

The  bottom  layer  is  the  KAPSE  layer.  It  is  composed  of  a  set 
of  Ada  packages  that  implement  the  kernal  function  of  the  Ada 
Programming  Support  Environment.  The  KAPSE  is  the  only  layer  that 
will  be  implemented  differently  on  different  host  machines,  but 
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regardless  of  implementation  its  functionalities  will  be  the  same 
over  all  instances  of  the  APSE.  Part  of  the  KAPSE  may  be 
implemented  in  another  language,  such  as  the  operating  system 
language  of  the  source  machine,  but  as  much  as  possible  should  be 
written  in  Ada  itself,  since  it  is  validatable.  No  other  layer 
should  have  any  non- Ada  code.  The  functionality  of  the  KAPSE 
should  be  defined  in  such  a  way  as  to  provide  a  general  purpose 
set  of  operating  system  type  primitives  which  are  robust  enough  to 
use  to  implement  the  rest  of  the  DAPSE.  The  functionality  of  the 
KAPSE  should  not  be  defined  in  such  a  way  as  to  prejudice  the 
implementation  of  the  KAPSE  toward  any  one  particular  architecture 
among  those  on  which  the  Ada  environment  must  run. 

Although  three  layers  have  been  defined,  this  does  not 
preclude  each  layer  from  being  broken  down  into  sub-layers  in 
implementation.  This  is,  in  fact,  anticipated  as  being  the 
natural  outgrowth  of  the  development  of  a  system  whose  underlying 
model  is  a  layered  one. 

VI.  RATIONALE  FOR  A  LAYERED  MODEL 

A  layered  model  follows  the  guidelines  set  forth  by  STONEMAN. 
It  aids  long  term  software  support  by  defining  and  consistently 
maintaining  the  functionality  of  the  KAPSE,  so  that  internal 
modifications  to  the  KAPSE  layer  will  not  affect  application 
software,  or  any  other  software  above  the  KAPSE  layer.  Since  any 
program  will  only  reference  those  programs  (or  packages)  in  the 
layer  immediately  below  its  own,  and  since  the  functionality  (but 
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not  necessarily  the  implementation)  of  those  programs  or  packages 
is  fixed  across  all  systems,  portability  for  all  software  above 
the  KAPSE  layer  is  enforced.  Since  all  protocols  and  interfaces 
are  clearly  defined  for  the  entire  system,  no  hidden  protocols 
exist.  By  rigidly  enforcing  one  means  of  inter-tool  communication 
through  the  KAPSE,  an  integrated  toolset  is  arrived  at  and 
uniformity  of  protocol  is  enforced.  A  layered  model  is  at  the 
same  time  both  simple  and  complete.  For  the  applications 
programmer,  the  APSE  is  a  set  of  procedures,  packages  and  tasks 
that  are  visible  to  his  program.  Thus  the  concepts  of  the  APSE 
are  those  of  the  Ada  language  itself,  and  the  most  straightforward 
possible.  By  judiciously  grouping  the  visible  packages  into  a 
small  but  well  organized  set  of  packages  the  functionality  of  the 
level  below  can  be  preorganized  for  the  programmer.  Only  the 
necessary  portions  of  the  packages  need  be  made  visible,  and  the 
rest  of  the  underlying  layer  need  not  concern  the  programmer. 
This  model  makes  the  APSE  an  easy  environment  to  use  as  a 
programmer  and  to  maintain  as  an  APSE  maintainer,  for  the  same 
reasons  that  abstraction  makes  any  system  easier  to  understand  and 
maintain. 

VII.  RATIONALE  FOR  THE  INTERFACE  LAYER 


Since  the  other  two  layers  have  been  present  in  both  the 
STONEMAN  model  and  the  LAPSE  model,  there  is  no  need  to  motivate 
their  presence  in  the  DAPSE  model.  The  Interface  layer,  however, 
needs  further  motivation.  The  first  argument  in  favor  of 
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including  this  layer  in  the  model  is  that  this  layer  was  really 
always  present.  In  STONEMAN,  the  Interlace  between  t  he  KAI'GK  and 
the  APSE  was  presumed  to  perform  all  of  the  functionality  now 
assigned  to  the  Interface  layer.  No  new  functionality  has  been 
added,  except  for  the  need  for  security  mechanisms  as  a  subset  of 
the  validation  mechanisms.  The  case  for  the  inclusion  of  security 
mechanisms  somewhere  in  the  model  has  already  been  made  by  [2). 
The  Interface  layer  is  where  these  mechanisms  belong,  along  with 
the  other  dynamic  validation  mechanisms.  The  second  argument  in 
favor  of  the  new  layer  is  that  the  interface  mechanisms  are  too 
complex,  and  their  effects  are  too  far  reaching  for  them  to  be 
ignored  in  the  design  of  the  APSE.  If  the  interfaces  are  to  be 
designed  then  they  must  be  visible  as  a  part  of  the  model.  They 
should  not  be  allowed  to  fall  into  the  crack  between  the  APSE  and 
KAPSE.  Thirdly,  since  validation  is  a  repeated  step  in  the  life 
of  all  APSEs,  it  is  better  to  provide  for  it  ahead  of  time.  This 
was  the  basic  thrust  of  the  recommendation  of  [2],  that  validation 
requirements  be  established  and  included  in  APSE  requirements 
specifications.  Finally,  since  security  must  be  considered  to 
completely  validate  an  APSE  system,  it  is  better  that  the  security 
mechanisms  also  be  designed  into  the  model  from  the  beginning, 
rather  than  added  after  the  design  has  been  completed.  This  is 
more  true  of  security  mechanisms  than  of  others  because  of  the 
subtle  nature  of  security  failures  and  the  low  level  at  which  most 
security  mechanisms  are  implemented. 


........ 


VIII.  DISTRIBUTED  ADA  PROGRAMMING  SUPPORT  ENVIRONMENTS 


The  concept  of  an  APSE  as  a  distributed  system  or  a 
configured  system  is  also  encompassed  by  the  layered  model.  As  in 
the  OSI  model  itself,  the  upper  layers  do  not  have  any  knowledge 
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Figure  3.  DAPSE  model  integrated  with  OSI  model 


about  the  physical  location  of  the  peer  process  with  which  they 
are  communicating.  The  KAPSE  layer  to  KAPSE  layer  protocol  is  the 
only  place  where  the  actual  locations  of  the  source  and 
destination  programs  must  be  considered.  If  the  source  and 
destination  are  on  the  same  physical  host,  then  communication  may 
be  as  modeled  above  (see  figure  2).  If  not,  then  the 
communication  is  via  the  network  linking  the  two  hosts.  It  is 


intended  that  the  networks  used  to  link  distributed  hosts  also  be 


PAGE  16 


modeled  after  the  OSI  reference  model.  Thus  the  model  is  expanded 
to  the  version  shown  in  figure  3  in  the  case  of  distributed 
communication.  In  fact,  only  a  part  of  the  KAPSE  layer,  the 
package  specifically  concerned  with  communication,  rather  than  the 
entire  KAPSE  layer,  need  be  concerned  with  whether  or  not  the 
source  and  destination  are  on  the  same  host. 

IX.  USER  COMMUNICATION  APPLIED  TO  DAPSE  MODEL 


The  issue  of  how  a  user  will  interface  to  the  APSE  is  one 
that  should  not  be  overlooked  or  put  off  until  late  in  the  design 
phase  if  it  is  to  be  a  natural  and  consistent  interface.  The 
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Figure  4.  Communication  with  Users  in  DAPSE 


layered  approach  handles  the  user  much  as  if  the  user  were  in  fact 
an  application  program:  that  is,  there  is  no  difference  between 
communication  with  the  user  and  communication  with  another  APSE 
program.  All  communication  goes  through  the  KAPSE,  and  the  KAPSE 
routes  the  'message'  back  up  through  the  appropriate  layers  to  its 
destination  (see  figure  4). 
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X.  CONCLUSIONS 


The  two  part  model  presented  in  STONEMAN  is  no  longer 
descriptive  enough  to  model  all  the  considerations  that  have  been 
added  since  STONEMAN.  A  previous  report  originated  the  idea  that 
the  OSI  model  be  used  as  the  underlying  model  of  APSEs.  It  is 
recommended  that  a  three  layered  model,  patterned  after  the  OSI  Reference 
model,  be  adopted  as  the  underlying  model  of  APSES. 

This  report  and  a  previous  one  have  motivated  the  need  for 
dynamic  validation.  It  Is  recommended  that  an  investigation  of  dynamic 
typechecking  and  validation  techniques  be  performed ,  and  that  the  results  be 
incorporated  into  the  design  of  the  middle  layer  of  the  proposed  model. 

Security,  as  a  subset  of  dynamic  validation,  is  a  necessary 
consideration  in  any  validation  system.  It  is  recommended  that  a 
security  mechanism  be  designed  and  incorporated  into  the  middle  layer  of  the 
proposed  model  as  early  as  possible  to  enforce  the  assertion  that  no 
KAPSE  facility  can  be  called  unless  the  appropriate  security  test 
has  been  passed. 

It  may  be  found  that  the  security  mechanisms  proposed  by  the 
research  recommended  above  are  difficult  or  impossible  to 
implement  in  Ada  as  it  is  now  defined.  It  is  recommended  that 
subsequent  research  be  undertaken  to  investigate  ways  in  which  Ada  could 
be  extended  to  include  security  and  validation  mechanisms  as  a  part  of  the 
language,  rather  than  as  a  part  of  the  APSE  or  Ada  Runtime  Support 
Environment . 
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